Conversation
![arnica-github-connector[bot]](https://avatars.githubusercontent.com/in/144692?s=60&v=4){kind=small}
| steps: | ||
| - uses: actions/checkout@v2 | ||
| - uses: actions/setup-python@v2 | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
Static Code Analysis Risk: Software and Data Integrity Failures - GitHub actions artipacked vulnerability
By default, actions/checkout persists a GitHub token in the checked-out repository's .git/config file so subsequent git operations can authenticate. This token typically has write access to repository contents. The credential remains on the runner filesystem for all subsequent steps, meaning a compromised or malicious step could exfiltrate it. Additionally, if an actions/upload-artifact step packages the workspace -- including the .git directory -- into an artifact, the credential becomes downloadable by anyone with access. While the default GITHUB_TOKEN expires after the workflow run completes, this pattern is especially dangerous when a repository configures long-lived credentials such as personal access tokens (PATs) or deploy keys, which would remain valid well beyond the run.
Recommendation: For actions/checkout findings, add persist-credentials: false in a with block directly under the uses line to prevent the token from being written to .git/config. For actions/upload-artifact findings, the suggested auto-fix (persist-credentials: false) is not a valid parameter for that action; instead, ensure the preceding actions/checkout step sets persist-credentials: false, and scope the artifact path to specific build output folders so .git is never included. If later steps need authenticated git operations, pass the token as a step-level environment variable (e.g., env: with GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}) rather than persisting it in the repository config where every subsequent step can access it.
Severity: Medium
Status: Open 🔴
References:
More details:
Take action by replying with an [arnica] command 💬
Actions
Use [arnica] or [a] to interact with the Arnica bot to acknowledge or dismiss code risks.
To acknowledge the finding as a valid code risk: [arnica] ack <acknowledge additional details>
To dismiss the risk with a reason: [arnica] dismiss <fp|accept|capacity> <dismissal reason>
Examples
-
[arnica] ack This is a valid risk and I'm looking into it -
[arnica] dismiss fp Dismissed - Risk Not Accurate: (i.e. False Positive) -
[arnica] dismiss accept Dismiss - Risk Accepted: Allow the risk to exist in the system -
[arnica] dismiss capacity Dismiss - No Capacity: This will need to wait for a future sprint
1 participant
Ticket: https://optimizely-ext.atlassian.net/browse/PMOD-3426
This PR updates the project’s Python version to 3.12.
Changes